@svlandeg tests are all green. Please review.

@adsharma, are there any other use cases beside the use case with external library you've mentioned?
Could it be useful for something else?

@YuriiMotov here's how I would like this work to be viewed:

The most general case is using meta programming to hide implementation details behind Pydantic and SQLModel.

In a large repository of many thousand SQLModels, you might want to defer work. Otherwise, model loading becomes slow and expensive.

Anytime you want to do multiple passes over the objects, you'll need the rebuild capability. So no, it's not something specific to my pet python library. Pydantic already implements it. But it's not lazy enough.

Thanks for quick reply!

In a large repository of many thousand SQLModels, you might want to defer work. Otherwise, model loading becomes slow and expensive.

But in current implementation (this PR) initialization is not deferred, right? It just allows to re-initialize model later.

Anytime you want to do multiple passes over the objects, you'll need the rebuild capability. So no, it's not something specific to my pet python library

I'm afraid it's a bit too abstract. Wen need more clear reasoning to move it forward.

I can imagine someone may want to dynamically add fields using decorators (e.g. for Multi-tenancy).
Like:

@add_client_specific_fields(client_id)
class Hero(SQLModel, table-True):
    pass

Is it a valid use case you have in mind for this feature?
Can you add a few more use cases?

But in current implementation (this PR) initialization is not deferred, right? It just allows to re-initialize model later.

That's right. But this file works as a standalone library. If you prefer it to be a part of this PR, I'm happy to contribute.

Re-initialize the model later has many good use cases:

• Model relationships (SQLModel objects) instead of exposing ids - an implementation detail. If someone wants to use UUID instead of int, it could be handled via meta programming instead of having to rewrite all the models.

• Declarative/Flexible ID generation. Do you want each table to have a different ID space or keep them all in one global ID space where objects are guaranteed to have unique IDs regardless of the type.

Most importantly, on repos like schema-org-python such re-initialize later flow improves startup time. The repo has about 1000 models.

dynamically add fields using decorators

yes, this is a valid use case. So are stacking other decorators:

@node
@sqlmodel
class SomeModel:
 ...

Would allow this table to be used as a node in a labelled property graph. You can further expose them via graphql or similar.

Would be nice if you could summarize use cases we discussed and update the description of this PR, so that we could hide some comments as resolved.
It would simplify the review process for Sebastian

Updated the summary. Please review.

Updated the summary. Please review.

Unfortunately, I think you misunderstood me..
For now the description looks like a promotion of your library. But I think we should focus on the question "Why introducing sqlmodel_rebuild() method is beneficial for SQLModel and its users. Why Sebastian should prioritize this task other hundreds other tasks?

In the last sentence of the description, I address "is it a promotion of a particular library?". It's certainly a promotion of some of the methods I discuss. I'm agnostic about where the code lives.

Are there other compositional techniques (stacking decorators) possible? Certainly. It's really a question for fastapi user community to come up with use cases.

Here's a more complete end to end example utilizing this approach.